You ain't gonna need it

"You ain't gonna need it" or “You aren′t gonna need it”[1] (acronym: YAGNI) is the principle in extreme programming that programmers should not add functionality until it is necessary.[2] Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."[3]

Contents

Rationale

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

Balancing concerns

Judging to omit a feature due to the YAGNI viewpoint should be balanced against other concerns, anticipating upcoming features, team expectations (or fears), availability of part-time expert assistance, and providing for completeness of functionality.

Note that the concept of avoiding unnecessary work with the YAGNI principle must be tempered against the potential need for refactoring software modules to make them simpler or faster in the future. If a software module, or an entire software product, represents a dead-end effort at the time, then any further modifications (such as refactoring) can be viewed as YAGNI issues. However, this concern is somewhat obviated by the effects of YAGNI itself - that is, it is always easier to refactor simpler code.

Another restriction is the potential for enhanced features for the customer. A feature which might seem unnecessary, at an early point, might become part of a vital future enhancement adding value to the product. Such judgments, assessing current and future features, should probably involve discussions with multiple people to help determine a "yes" or "no" decision about implementing such features.

Also affecting the decision is the impact of fear or confusion for the people involved with a new feature. An individual or team working on a new enhancement might face disappointment if the new work is denied, or demanded, against their personal expectations, either excited about the new work, or dreading the anticipated workload, associated with a particular feature. This concern should obviously be handled well prior to YAGNI principles being applied.

Yet another conflicting factor is the access to expert assistance, which might be limited. For example, experts might be available to design features X, Y, or Z, and also recommend another, but currently unneeded, feature W. A judgment call is needed to determine whether such expert design of an unneeded feature should be encouraged, while the expert is available, to support potential product enhancement in the future, where enhancements would be implemented by junior personnel after the expert has left.

A logical conflicting factor is the notion of completeness, which tends to define missing options, or facets, mostly likely to be needed: for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items". The critical impact of completeness can be seen in some types of wiki-collaboration software which can add or delete image-files, but not rename images.

In general, the YAGNI viewpoint must be balanced against the other concerns, such as those of refactoring, upcoming vital features, team expectations, part-time expert assistance, and logical completeness.

See also

References

  1. ^ "You Arent Gonna Need It". C2 wiki. http://c2.com/xp/YouArentGonnaNeedIt.html. Retrieved 2011-12-6. 
  2. ^ Lowell Lindstrom; Carmen Zannier; Erdogmus, Hakan (2004). "Extreme Programming and Agile Methods". XP/Agile Universe 2004: 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, August 15–18 (Lecture Notes in Computer Science). Berlin: Springer. p. 121. ISBN 3-540-22839-X. 
  3. ^ Ron Jeffries. "Practices". X Programming. http://www.xprogramming.com/Practices/PracNotNeed.html. Retrieved 2007-11-07.